Along with diffusion of information processing devices such as personal computers, PDAs, cellular phones, and the like in recent years, it is conceivable that a technique for providing a service by use of a so-called digital ticket (hereinafter referred simply to as a ticket in the present invention) will become widespread. Such a ticket allows fraudulent duplication because of the nature of electronic data. Accordingly, it is conceivable to be increasingly necessary to prevent acts of performing multiple accesses by use of a fraudulently duplicated ticket (hereinafter referred to as multiple uses).
Although such fraudulent acts must be eliminated, the ticket in the present invention is a piece of electronic data, and it is difficult to prevent the multiple uses of the duplicated ticket only by means of a software unit.
Therefore, it is understood that elimination of the above-described fraudulent acts must depend on hardware to some extent. However, a security device implemented in hardware has a limitation in hardware resources allocatable for this purpose. For this reason, with regard to conventionally used security devices, it is also conceivable that data for preventing the fraudulent acts must be stored in an area outside the security device. In this case, it is possible to execute complicated encryption processing between the security device and the external area. However, such processing may cause response delays in transactions and may damage efficiency of using electronic tickets. On the other hand, a method of storing the data for preventing fraudulent acts in the external area has a disadvantage of damaging reliability of the security device itself due to fraudulent accesses to the data for preventing the fraudulent acts.
A method of storing an encryption key in an encrypted format outside the security device has been heretofore known. However, it is hard to say that the method sufficiently addresses a question of restricting the number of signatures, i.e. restricting the multiple uses. In this case, it is also conceivable to add a counter to a key Blob. However, reliability of the counter must be assured at the same time. Accordingly, adoption of a data format in which the counter is simply added is not sufficient in terms of eliminating the fraudulent multiple uses.
The following document is considered:                [Non-patent document 1]                    Terada et al., “Copy Prevention Scheme for Rights Trading Infrastructure”, Journal of Information Processing Society of Japan, Vol. 42, No. 8, August 2001, pp. 2017-2029                        
Meanwhile, there has been disclosed a technique configured to delete a token representing a ticket from hardware after use, (See non-patent document 1). In this case, it is essential to validate whether this token is reliable. Accordingly, a key issued by a certificate site should be retained in the hardware. However, to assure safe storage of this key involves additional complexity and a new threat to reliability.
In other words, it has been heretofore deemed necessary to impart highly reliable number identification capability to data such as digital tickets which require prevention of fraudulent uses. Moreover, it has been deemed necessary to prevent fraudulent uses of data such as tickets with high reliability only by adding minimum hardware resources.